Welcome to the June 2023 report from the Reproducible Builds project In our reports, we outline the most important things that we have been up to over the past month. As always, if you are interested in contributing to the project, please visit our Contribute page on our website.

Corrupted build environments can deliver compromised cryptographically signed binaries. Several exploits in critical supply chains have been demonstrated in recent years, proving that this is not just theoretical. The most well secured build environments are still single points of failure when they fail. [ ] This talk will focus on the state of the art from several angles in related Free and Open Source Software projects, what works, current challenges and future plans for building trustworthy toolchains you do not need to trust.

The 2020 Solarwinds attack was a tipping point that caused a heightened awareness about the security of the software supply chain and in particular the large amount of trust placed in build systems. Reproducible Builds (R-Bs) provide a strong foundation to build defenses for arbitrary attacks against build systems by ensuring that given the same source code, build environment, and build instructions, bitwise-identical artifacts are created.

We conducted a series of 24 semi-structured expert interviews with participants from the Reproducible-Builds.org project, and iterated on our questions with the reproducible builds community. We identified a range of motivations that can encourage open source developers to strive for R-Bs, including indicators of quality, security benefits, and more efficient caching of artifacts. We identify experiences that help and hinder adoption, which heavily include communication with upstream projects. We conclude with recommendations on how to better integrate R-Bs with the efforts of the open source and free software community.

• Martin Monperrus asked whether there are any project[s] where reproducibility is checked in a continuous integration pipeline? which received a number of replies from various projects.
• Vagrant Cascadian mentioned that Packaging Con 2023 is being held in Berlin, the weekend before the Reproducible Builds summit later this year. In particular, Vagrant noticed that the Call for Proposals (CFP) closes at the end of July.
• Larry Doolittle was searching Usenet archives and discovered a thread from December 1999 titled Time independent checksum(cksum) on comp.unix.programming. Larry notes that it starts with Jayan asking about comparing binaries that might have difference in their embedded timestamps (that is, perhaps, Foreshadowing diffoscope, amiright? ) and goes on to observe that:

The antagonist is David Schwartz, who correctly says There are dozens of complex reasons why what seems to be the same sequence of operations might produce different end results, but goes on to say I totally disagree with your general viewpoint that compilers must provide for reproducability [sic]. Dwight Tovey and I (Larry Doolittle) argue for reproducible builds. I assert Any program especially a mission-critical program like a compiler that cannot reproduce a result at will is broken. Also it s commonplace to take a binary from the net, and check to see if it was trojaned by attempting to recreate it from source.

Distribution work 27 reviews of Debian packages were added, 40 were updated and 8 were removed this month adding to our knowledge about identified issues. A new randomness_in_documentation_generated_by_mkdocs toolchain issue was added by Chris Lamb [ ], and the deterministic flag on the paths_vary_due_to_usrmerge issue as we are not currently testing usrmerge issues [ ] issues.
Roland Clobus posted his 18th update of the status of reproducible Debian ISO images on our mailing list. Roland reported that all major desktops build reproducibly with bullseye, bookworm, trixie and sid , but he also mentioned amongst many changes that not only are the non-free images being built (and are reproducible) but that the live images are generated officially by Debian itself. [ ]
Jan-Benedict Glaw noticed a problem when building NetBSD for the VAX architecture. Noting that Reproducible builds [are] probably not as reproducible as we thought , Jan-Benedict goes on to describe that when two builds from different source directories won t produce the same result and adds various notes about sub-optimal handling of the CFLAGS environment variable. [ ]
F-Droid added 21 new reproducible apps in June, resulting in a new record of 145 reproducible apps in total. [ ]. (This page now sports missing data for March May 2023.) F-Droid contributors also reported an issue with broken resources in APKs making some builds unreproducible. [ ]
Bernhard M. Wiedemann published another monthly report about reproducibility within openSUSE

---

Upstream patches

• Bernhard M. Wiedemann:
  • bcachefs (sort find / filesys)
  • build-compare (reports files as identical)
  • build-time (toolchain date)
  • cockpit (merged, gzip mtime)
  • gcc13 (gcc13 toolchain LTO parallelism)
  • ghc-rpm-macros (toolchain parallelism)
  • golangcli-lint (date)
  • gutenprint (date+time)
  • mage (date (golang))
  • mumble (filesys)
  • pcr (date)
  • python-nss (drop sphinx .doctrees)
  • python310 (merged, bisected+backported)
  • warpinator (merged, date)
  • xroachng (date)
• Chris Lamb:
  • #1037159 filed against elinks.
  • #1037205 filed against multipath-tools.
  • #1037216 filed against mkdocstrings-python-handlers.
  • #1038730 filed against fribidi.
  • #1038957 filed against jtreg7.
  • #1039932 filed against python-bitstring (forwarded upstream).
• Vagrant Cascadian:
  • #1037235 filed against gradle-kotlin-dsl.
  • #1037240 filed against libsdl-console.
  • #1037267 filed against kawari8.
  • #1037269 filed against freetds.
  • #1037272 filed against gbrowse.
  • #1037276 filed against bglibs.
  • #1037277 filed against advi.
  • #1037278 filed against afterstep.
  • #1037280 filed against simstring.
  • #1037296 filed against manderlbot.
  • #1037298 filed against erlang-proper.
  • #1037300 filed against comedilib.
  • #1037309 filed against libint.
  • #1037427 filed against newlib.
  • #1038908 filed against binutils-msp430.
  • #1038970 & #1038971 filed against c-munipack.
  • #1039044 filed against python-marshmallow-sqlalchemy.
  • #1039457 filed against mplayer.
  • #1039493 & #1039500 filed against menu.
  • #1039506 filed against mini-buildd.
  • #1039610 filed against pnetcdf.
  • #1039617 & #1039618 filed against liblopsub.
  • #1039619 filed against wcc.
  • #1039623 filed against shotcut.
  • #1039624 filed against icu.
  • #1039741 filed against libapache-poi-java.
  • #1039808 filed against atf.
  • #1039865 filed against valgrind.

---

Testing framework The Reproducible Builds project operates a comprehensive testing framework (available at tests.reproducible-builds.org) in order to check packages and other artifacts for reproducibility. In June, a number of changes were made by Holger Levsen, including:

• Additions to a (relatively) new Documented Jenkins Maintenance (djm) script to automatically shrink a cache & save a backup of old data [ ], automatically split out previous months data from logfiles into specially-named files [ ], prevent concurrent remote logfile fetches by using a lock file [ ] and to add/remove various debugging statements [ ].
• Updates to the automated system health checks to, for example, to correctly detect new kernel warnings due to a wording change [ ] and to explicitly observe which old/unused kernels should be removed [ ]. This was related to an improvement so that various kernel issues on Ubuntu-based nodes are automatically fixed. [ ]

Holger and Vagrant Cascadian updated all thirty-five hosts running Debian on the amd64, armhf, and i386 architectures to Debian bookworm, with the exception of the Jenkins host itself which will be upgraded after the release of Debian 12.1. In addition, Mattia Rizzolo updated the email configuration for the @reproducible-builds.org domain to correctly accept incoming mails from jenkins.debian.net [ ] as well as to set up DomainKeys Identified Mail (DKIM) signing [ ]. And working together with Holger, Mattia also updated the Jenkins configuration to start testing Debian trixie which resulted in stopped testing Debian buster. And, finally, Jan-Benedict Glaw contributed patches for improved NetBSD testing.

---

If you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:

• IRC: #reproducible-builds on irc.oftc.net.
• Mailing list: rb-general@lists.reproducible-builds.org
• Twitter: @ReproBuilds

r2u on colab focal

download.file("https://github.com/eddelbuettel/r2u/raw/master/inst/scripts/add_cranapt_focal.sh",
              "add_cranapt_focal.sh")
Sys.chmod("add_cranapt_focal.sh", "0755")
system("./add_cranapt_focal.sh")
install.packages("tidyverse")
library(tidyverse)
install.packages("brms")
library(brms)

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Changes in Rcpp version 1.0.11 (2023-07-03)

• Changes in Rcpp API:
  • Rcpp:::CxxFlags() now quotes only non-standard include path on linux (Lukasz in #1243 closing #1242).
  • Two unit tests no longer accidentally bark on stdout (Dirk and I aki in #1245).
  • Compilation under C++20 using clang++ and its standard library is enabled (Dirk in #1248 closing #1244).
  • Use backticks in a generated .Call() statement in RcppExports.R (Dirk #1256 closing #1255).
  • Switch to system2() to capture standard error messages in error cases (I aki in #1259 and #1261 fixing #1257).
• Changes in Rcpp Documentation:
  • The CITATION file format has been updated (Dirk in #1250 fixing #1249).
• Changes in Rcpp Deployment:
  • A test for qnorm now uses the more accurate value from R 4.3.0 (Dirk in #1252 and #1260 fixing #1251).
  • Skip tests with path issues on Windows (I aki in #1258).
  • Container deployment in continuous integrations was improved. (I aki and Dirk in #1264, Dirk in #1269).
  • Several files receives minor edits to please R CMD check from r-devel (Dirk in #1267).

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

• Dar itself is both a library (with C++ and Python bindings) for interacting with data, and a CLI tool (dar itself).
• Alongside this, there is an ecosystem of tools around dar, including GUIs for multiple platforms, backup scripts, and FUSE implementations.
• Dar is like tar in that it can read and write files sequentially if desired. Dar archives can be streamed, just like tar archives. But dar takes it further; if you have dar_slave on the remote end, random access is possible over ssh (dramatically speeding up certain operations).
• Dar is like zip in that a dar archive contains a central directory (called a catalog) which permits random access to the contents of an archive. In other words, you don t have to read an entire archive to extract just one file (assuming the archive is on disk or something that itself permits random access). Also, dar can compress each file individually, rather than the tar approach of compressing the archive as a whole. This increases archive performance (dar knows not to try to compress already-compressed data), boosts restore resilience (corruption of one part of an archive doesn t invalidate the entire rest of it), and boosts restore performance (permitting random access).
• Dar can split an archive into multiple pieces called slices, and it can even split member files among the slices. The catalog contains information allowing you to know which slice(s) a given file is saved in.
• The catalog can also be saved off in a file of its own (dar calls this an isolated catalog ). Isolated catalogs record just metadata about files archived.
• dar_manager can assemble a database by reading archives or isolated catalogs, letting you know where files are stored and facilitating restores using the minimal number of discs.
• Dar supports differential/incremental backups, which record changes since the last backup. These backups record not just additions, but also deletions. dar can optionally use rsync-style binary deltas to minimize the space needed to record changes. Dar does not suffer from GNU tar s data loss bug with incrementals.
• Dar can slice and dice archives like Perl does strings. The usage notes page shows how you can merge archives, create decremental archives (where the full backup always reflects the current state of the system, and incrementals go backwards in time instead of forwards), etc. You can change the compression algorithm on an existing archive, re-slice it, etc.
• Dar is extremely careful about preserving all metadata: hard links, sparse files, symlinks, timestamps (including subsecond resolution), EAs, POSIX ACLs, resource forks on Mac, detecting files being modified while being read, etc. It makes a nice way to copy directories, sort of similar to rsync -avxHAXS.

• $SOURCEDIR is the directory being backed up
• $DRIVE is the directory for backups to be stored in. Since dar can split by a specified size, I don t need to make separate filesystems to simulate the separate drive experience as I did with git-annex.
• $CATDIR will hold isolated catalogs
• $DARDB points to the dar_manager database

• verbose does what you expect
• create selects the operation mode (like tar -c) and gives the archive basename
• on-fly-isolate says to write an isolated catalog as well, right while making the archive. You can always create an isolated catalog later (which is fast, since it only needs to read the last bits of the last slice) but it s more convenient to do it now, so we do. We give the base name for the isolated catalog also.
• slice 400M says to split the archive, and create slices 400MB each.
• min-digits 2 pertains to naming files. Without it, dar would create files named bak1.dar.1, bak1.dar.2, bak1.dar.10, etc. dar works fine with this, but it can be annoying in ls. This is just convenience for humans.
• pause tells dar to pause after writing each slice. This would let us swap drives, burn discs, etc. I do this for demonstration purposes only; it isn t strictly necessary in this situation. For a more powerful option, dar also supports execute, which can run commands after each slice.
• fs-root gives the path to actually back up.

• Renamed a file to file01-unchanged
• Deleted a file
• Copied /bin/cp to a file named cp

1. A file that was not changed from the initial backup. Its presence was simply noted, but because we re doing an incremental, the data wasn t saved.
2. A file that is saved in this incremental, on slice 1.
3. The two deleted files

• Use dar to simply extract each archive in order. It will handle deletions, renames, etc. along the way.
• Use dar_manager with the backup database to do manage the process. It may be somewhat more efficient, as it won t bother to restore files that will later be modified or deleted.

Changes in Rcpp release version 1.0.10 (2023-01-12)

• Changes in Rcpp API:
  • Unwind protection is enabled by default (I aki in #1225). It can be disabled by defining RCPP_NO_UNWIND_PROTECT before including Rcpp.h. RCPP_USE_UNWIND_PROTECT is not checked anymore and has no effect. The associated plugin unwindProtect is therefore deprecated and will be removed in a future release.
  • The 'finalize' method for Rcpp Modules is now eagerly materialized, fixing an issue where errors can occur when Module finalizers are run (Kevin in #1231 closing #1230).
  • Zero-row data.frame objects can receive push_back or push_front (Dirk in #1233 fixing #1232).
  • One remaining sprintf has been replaced by snprintf (Dirk and Kevin in #1236 and #1237).
  • Several conversion warnings found by clang++ have been addressed (Dirk in #1240 and #1241).
• Changes in Rcpp Attributes:
  • The C++20, C++2b (experimental) and C++23 standards now have plugin support like the other C++ standards (Dirk in #1228).
  • The source path for attributes received one more protection from spaces (Dirk in #1235 addressing #1234).
• Changes in Rcpp Deployment:
  • Several GitHub Actions have been updated.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Perhaps we need to rethink what is meant by a gimmick. If a gimmick is anything that we want to reject as extra or excessive or ill-fitting, then it may be important to ask what inhibitions or arbitrary conventions have made it seem like excess, and to revel in the exorbitant fictional constructions it produces. [...]

We are humanitarian and chivalrous; we don t want to enslave other races, we simply want to bequeath them our values and take over their heritage in exchange. We think of ourselves as the Knights of the Holy Contact. This is another lie. We are only seeking Man. We have no need of other worlds. We need mirrors. We don t know what to do with other worlds. A single world, our own, suffices us; but we can t accept it for what it is. We are searching for an ideal image of our own world: we go in quest of a planet, of a civilisation superior to our own, but developed on the basis of a prototype of our primaeval past. At the same time, there is something inside us that we don t like to face up to, from which we try to protect ourselves, but which nevertheless remains since we don t leave Earth in a state of primal innocence. We arrive here as we are in reality, and when the page is turned, and that reality is revealed to us that part of our reality that we would prefer to pass over in silence then we don t like it anymore.

Man has gone out to explore other worlds and other civilizations without having explored his own labyrinth of dark passages and secret chambers and without finding what lies behind doorways that he himself has sealed.

[Solaris] renders unnecessary any more alien stories. Nothing further can be said on this topic ...] Possibly, it can be said that when one feels the urge for such a thing, one should simply reread Solaris and learn its lessons again. Kim Stanley Robinson [...]

Before I start work, I browse through some photos of friends who are doing better than me, then an article on a black teenager who was killed on 115th for holding a weapon later identified as a showerhead, then an article on a black woman who was killed on the Grand Concourse for holding a weapon later identified as a cell phone, then I drown myself in the comments section and do some online shopping, by which I mean I put four dresses in my cart as a strictly theoretical exercise and then let the page expire.

• format the document source for legible reading. Yes, it's the input to the typesetter, and yes, the output of the typesetter needs to be legible. But it's worth making the input easy to read, too. Because
• avoid rebuilding your rendered document too often. It's slow, it takes you out of the activity of writing, and it throws up lots of opportunities to get distracted by some rendering nit that you didn't realise would happen.
• Unless you are very good at manoeuvring around long documents, liberally split them up. I think it's fine to have sections in their own source files.
• Machine-assisted moving around documents is good. If you use (neo)vim, you can tweak exuberant-ctags to generate more useful tags for LaTeX documents than what you get OOTB, including jumping to \label s and the BibTeX source of \cite s. See this stackoverflow post.
• If you use syntax highlighting in your editor, take a long, hard look at what it's drawing attention to. It's not your text, that's for sure. Is it worth having it on? Consider turning it off. Or (yak shaving beware!) tweak it to de-emphasise things, instead of emphasising them. One small example for (neo)vim, to change tokens recognised as being "todo" to match the styling used for comments (which is normally de-emphasised):

  hi def link texTodo Comment
  

• I stick a line of 78 '%' characters between each section and sub-section. This helps to visually break them up and finding them in a scroll-past is quicker.
• I indent as much of the content as I can in each chapter/section/subsection (however deep I go in sections) to tie them to the section they belong to and see at a glance how deep I am in subsections, just like with source code. The exception is environments that I can't due to other tool limitations: I have code excerpts demarked by \begin code /\end code which are executed by Haskell's GHCi interpreter, and the indentation can interfere with Haskell's indentation rules.
• For large documents (like a thesis), I have little helper "standalone" .tex files whose purpose is to let me build just one chapter or section at a time.
• I'm fairly sure I'll settle on a serif font for my final document. But I have found that a sans-serif font is easier on my eyes on-screen. YMMV.

• Don't stop to write a blog post about it.

Recap In the previous article, I touched on those projects:

Terminal	Changes since review
Alacritty	releases! scrollback, better latency, URL launcher, clipboard support, still not in Debian, but close
GNOME Terminal	not much? couldn't find a changelog
Konsole	outdated changelog, color, image previews, clickable files, multi-input, SSH plugin, sixel images
mlterm	long changelog but: supports console mode (like GNU screen?!), Wayland support through libvte, sixel graphics, zmodem, mosh
pterm	changes: Wayland support
st	unparseable changelog, suggests scroll(1) or scrollback.patch for scrollback now
Terminator	moved to GitHub, Python 3 support, not being dead
urxvt	no significant changes, a single release, still in CVS!
Xfce Terminal	hard to parse changelog, presumably some improvements to paste safety?
xterm	notoriously hard to parse changelog, improvements to paste safety (disallowedPasteControls), fonts, clipboard improvements?

After writing those articles, bizarrely, I was still using rxvt even though it did not come up as shiny as I would have liked. The colors problems were especially irritating. I briefly played around with Konsole and xterm, and eventually switched to XTerm as my default x-terminal-emulator "alternative" in my Debian system, while writing this. I quickly noticed why I had stopped using it: clickable links are a huge limitation. I ended up adding keybindings to open URLs in a command. There's another keybinding to dump the history into a command. Neither are as satisfactory as just clicking a damn link.

Requirements Figuring out my requirements is actually a pretty hard thing to do. In my last reviews, I just tried a bunch of stuff and collected everything, but a lot of things (like tab support) I don't actually care about. So here's a set of things I actually do care about:

• latency
• resource usage
• proper clipboard support, that is:
  • mouse selection and middle button uses PRIMARY
  • control-shift-c and control-shift-v for CLIPBOARD
• true color support
• no known security issues
• active project
• paste protection
• clickable URLs
• scrollback
• font resize
• non-destructive text-wrapping (ie. resizing a window doesn't drop scrollback history)
• proper unicode support (at least latin-1, ideally "everything")
• good emoji support (at least showing them, ideally "nicely"), which involves font fallback

Latency is particularly something I wonder about in Wayland. Kitty seem to have been pretty dilligent at doing latency tests, claiming 35ms with a hardware-based latency tester and 7ms with typometer, but it's unclear how those would come up in Wayland because, as far as I know, typometer does not support Wayland.

Candidates Those are the projects I am considering.

• darktile - GPU rendering, Unicode support, themable, ligatures (optional), Sixel, window transparency, clickable URLs, true color support, not in Debian
• foot - Wayland only, daemon-mode, sixel images, scrollback search, true color, font resize, URLs not clickable, but keyboard-driven selection, proper clipboard support, in Debian
• havoc - minimal, scrollback, configurable keybindings, not in Debian
• sakura - libvte, Wayland support, tabs, no menu bar, original libvte gangster, dynamic font size, probably supports Wayland, in Debian
• termonad - Haskell? in Debian
• wez - Rust, Wayland, multiplexer, ligatures, scrollback search, clipboard support, bracketed paste, panes, tabs, serial port support, Sixel, Kitty, iTerm graphics, built-in SSH client (!?), not in Debian
• XTerm - status quo, no Wayland port obviously
• zutty: OpenGL rendering, true color, clipboard support, small codebase, no Wayland support, crashes on bremner's, in Debian

Candidates not considered

Alacritty I would really, really like to use Alacritty, but it's still not packaged in Debian, and they haven't fully addressed the latency issues although, to be fair, maybe it's just an impossible task. Once it's packaged in Debian, maybe I'll reconsider.

Kitty Kitty is a "fast, feature-rich, GPU based", with ligatures, emojis, hyperlinks, pluggable, scriptable, tabs, layouts, history, file transfer over SSH, its own graphics system, and probably much more I'm forgetting. It's packaged in Debian. So I immediately got two people commenting (on IRC) that they use Kitty and are pretty happy with it. I've been hesitant in directly talking about Kitty publicly, but since it's likely there will be a pile-up of similar comments, I'll just say why it's not the first in my list, even if it might, considering it's packaged in Debian and otherwise checks all the boxes. I don't trust the Kitty code. Kitty was written by the same author as Calibre, which has a horrible security history and generally really messy source code. I have tried to do LTS work on Calibre, and have mostly given up on the idea of making that program secure in any way. See calibre for the details on that. Now it's possible Kitty is different: it's quite likely the author has gotten some experience writing (and maintaining for so long!) Calibre over the years. But I would be more optimistic if the author's reaction to the security issues were more open and proactive. I've also seen the same reaction play out on Kitty's side of things. As anyone who worked on writing or playing with non-XTerm terminal emulators, it's quite a struggle to make something (bug-for-bug) compatible with everything out there. And Kitty is in that uncomfortable place right now where it diverges from the canon and needs its own entry in the ncurses database. I don't remember the specifics, but the author also managed to get into fights with those people as well, which I don't feel is reassuring for the project going forward. If security and compatibility wasn't such big of a deal for me, I wouldn't mind so much, but I'll need a lot of convincing before I consider Kitty more seriously at this point.

Next steps It seems like Arch Linux defaults to foot in Sway, and I keep seeing it everywhere, so it is probably my next thing to try, if/when I switch to Wayland. One major problem with foot is that it's yet another terminfo entry. They did make it into ncurses (patch 2021-07-31) but only after Debian bullseye stable was released. So expect some weird compatibility issues when connecting to any other system that is older or the same as stable (!). One question mark with all Wayland terminals, and Foot in particular, is how much latency they introduce in the rendering pipeline. The foot performance and benchmarks look excellent, but do not include latency benchmarks.

No conclusion So I guess that's all I've got so far, I may try alacritty if it hits Debian, or foot if I switch to Wayland, but for now I'm hacking in xterm still. Happy to hear ideas in the comments. Stay tuned for more happy days.

Changes in Rcpp hotfix release version 1.0.9 (2022-07-02)

• Changes in Rcpp API:
  • Accomodate C++98 compilation by adjusting attributes.cpp (Dirk in #1193 fixing #1192)
  • Accomodate newest compilers replacing deprecated std::unary_function and std::binary_function with std::function (Dirk in #1202 fixing #1201 and CRAN request)
  • Upon removal from precious list, the tag is set to null (I aki in #1205 fixing #1203)
  • Move constructor and assignment for strings have been added (Dean Scarff in #1219).
• Changes in Rcpp Documentation:
  • Adjust one overflowing column (Bill Denney in #1196 fixing #1195)
  • Correct a typo in the FAQ (Marco Colombo in #1217)
• Changes in Rcpp Deployment:
  • Accomodate four digit version numbers in unit test (Dirk)
  • Do not run complete test suite to limit test time to CRAN preference (Dirk in #1206)
  • Small updates to the CI test containers have been made
  • Some of changes also applied to an interim release 1.0.8.3 made for CRAN on 2022-03-14.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

https://www.youtube.com/feeds/videos.xml?channel_id=<id goes here>

You can also use get a feed directly with a username:
https://www.youtube.com/feeds/videos.xml?user=<username>
The one I use most is the one for playlists (if creators remember to
use them).
https://www.youtube.com/feeds/videos.xml?playlist_id=<playlist id>

Changes in Rcpp hotfix release version 1.0.8.3 (2022-03-14)

• Changes in Rcpp API:
  • Accomodate C++98 compilation by adjusting attributes.cpp (Dirk in #1193 fixing #1192)
  • Accomodate newest compilers replacing deprecated std::unary_function and std::binary_function with std::function (Dirk in #1202 fixing #1201 and CRAN request)
• Changes in Rcpp Documentation:
  • Adjust one overflowing column (Bill Denney in #1196 fixing #1195)
• Changes in Rcpp Deployment:
  • Accomodate four digit version numbers in unit test (Dirk)
  • Do not run complete test suite to limit test time to CRAN preference (Dirk)

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Changes in Rcpp hotfix release version 1.0.8.2 (2022-03-10)

• Changes in Rcpp API:
  • Accomodate C++98 compilation by adjusting attributes.cpp (Dirk in #1193 fixing #1192)
  • Accomodate newest compilers replacing deprecated std::unary_function and std::binary_function with std::function (Dirk in #1202 fixing #1201 and CRAN request)
• Changes in Rcpp Documentation:
  • Adjust one overflowing column (Bill Denney in #1196 fixing #1195)
• Changes in Rcpp Deployment:
  • Accomodate four digit version numbers in unit test (Dirk)

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

• Find a list of packages(failing rebuild and testing with autopkgtest, of reverse dependencies of webpack and nodejs) to fix.
• See if new upstream versions are available that support nodejs16 and webpack5 respectively.
• See if the new upstream version works and doesn't fail while rebuilding or testing with autopkgtest.
• Report bug in Debian if any fails to rebuild or test with autopkgtest.
• Forward bugs upstream if needed.
• Fix packages and forward patches.

• I aki generalized use of finalizers for external pointers in #1180
• Kevin ensured include paths are always quoted in #1189
• Dirk added new headers to allow a more fine-grained choice of Rcpp feature for faster builds in #1191
• Travers Ching extended the function signature generator to allow for a default R argument in #1184 and #1187
• Dirk extended documentation, removed old example code, updated references and refreshed CI setup in several PRs (see below)

Changes in Rcpp release version 1.0.8 (2022-01-11)

• Changes in Rcpp API:
  • STRICT_R_HEADERS is now enabled by default, see extensive discussion in #1158 closing #898.
  • A new #define allows default setting of finalizer calls for external pointers (I aki in #1180 closing #1108).
  • Rcpp:::CxxFlags() now quotes the include path generated, (Kevin in #1189 closing #1188).
  • New header files Rcpp/Light, Rcpp/Lighter, Rcpp/Lightest and default Rcpp/Rcpp for fine-grained access to features (and compilation time) (Dirk #1191 addressing #1168).
• Changes in Rcpp Attributes:
  • A new option signature allows customization of function signatures (Travers Ching in #1184 and #1187 fixing #1182)
• Changes in Rcpp Documentation:
  • The Rcpp FAQ has a new entry on how not to grow a vector (Dirk in #1167).
  • Some long-spurious calls to RNGSope have been removed from examples (Dirk in #1173 closing #1172).
  • DOI reference in the bibtex files have been updated per JSS request (Dirk in #1186).
• Changes in Rcpp Deployment:
  • Some continuous integration components have been updated (Dirk in #1174, #1181, and #1190).

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Vetch had been three years at the School and soon would be made Sorcerer; he thought no more of performing the lesser arts of magic than a bird thinks of flying. Yet a greater, unlearned skill he possessed, which was the art of kindness.

I ll explore how I go about identifying issues to work on, learn more about the specific issues, recreate the problem locally, isolate the potential causes, dissect the problem into identifiable parts, and adapt the packaging and/or source code to fix the issues.

In the role of a packager, updating packages is a recurring task. For some projects, a packager is involved in upstream maintenance, or well written release notes make it easy to figure out what changed between the releases. This isn t always the case, for instance with some small project maintained by one or two people somewhere on GitHub, and it can be useful to verify what exactly changed. Diffoscope can help determine the changes between package releases. [ ]

diffoscope diffoscope is our in-depth and content-aware diff utility. Not only can it locate and diagnose reproducibility issues, it can provide human-readable diffs from many kinds of binary formats. This month, Chris Lamb made the following changes, including preparing and uploading versions 190, 191, 192, 193 and 194 to Debian:

• New features:
  • Continue loading a .changes file even if the referenced files do not exist, but include a comment in the returned diff. [ ]
  • Log the reason if we cannot load a Debian .changes file. [ ]
• Bug fixes:
  • Detect XML files as XML files if file(1) claims if they are XML files or if they are named .xml. (#999438)
  • Don t duplicate file lists at each directory level. (#989192)
  • Don t raise a traceback when comparing nested directories with non-directories. [ ]
  • Re-enable test_android_manifest. [ ]
  • Don t reject Debian .changes files if they contain non-printable characters. [ ]
• Codebase improvements:
  • Avoid aliasing variables if we aren t going to use them. [ ]
  • Use isinstance over type. [ ]
  • Drop a number of unused imports. [ ]
  • Update a bunch of %-style string interpolations into f-strings or str.format. [ ]
  • When pretty-printing JSON, mark the difference as being reformatted, additionally avoiding including the full path. [ ]
  • Import itertools top-level module directly. [ ]

Chris Lamb also made an update to the command-line client to trydiffoscope, a web-based version of the diffoscope in-depth and content-aware diff utility, specifically only waiting for 2 minutes for try.diffoscope.org to respond in tests. (#998360) In addition Brandon Maier corrected an issue where parts of large diffs were missing from the output [ ], Zbigniew J drzejewski-Szmek fixed some logic in the assert_diff_startswith method [ ] and Mattia Rizzolo updated the packaging metadata to denote that we support both Python 3.9 and 3.10 [ ] as well as a number of warning-related changes[ ][ ]. Vagrant Cascadian also updated the diffoscope package in GNU Guix [ ][ ].

Distribution work In Debian, Roland Clobus updated the wiki page documenting Debian reproducible Live images to mention some new bug reports and also posted an in-depth status update to our mailing list. In addition, 90 reviews of Debian packages were added, 18 were updated and 23 were removed this month adding to our knowledge about identified issues. Chris Lamb identified a new toolchain issue, absolute_path_in_cmake_file_generated_by_meson.
Work has begun on classifying reproducibility issues in packages within the Arch Linux distribution. Similar to the analogous effort within Debian (outlined above), package information is listed in a human-readable packages.yml YAML file and a sibling README.md file shows how to classify packages too. Finally, Bernhard M. Wiedemann posted his monthly reproducible builds status report for openSUSE and Vagrant Cascadian updated a link on our website to link to the GNU Guix reproducibility testing overview [ ].

Software development The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where appropriate. This month, we wrote a large number of such patches, including:

• Bernhard M. Wiedemann:
  • ck (build failure in single-CPU machine)
  • libfabric (date-related issue)
  • python-dukpy-kovidgoyal (filesystem ordering)
  • python-thriftpy2 (build failure in the far future)
  • smplayer (date)
• Chris Lamb:
  • #998312 filed against ibus-input-pad.
  • #999848 filed against node-cssstyle.
  • #999866 filed against liboqs.
  • #1000326 filed against xrstools.
  • #1000327 filed against meson (forwarded).
  • #1000401 filed against golang-github-go-git-go-git.
  • #1000531 filed against sphinxcontrib-applehelp.
  • #1000532 filed against sphinxcontrib-jsmath.
  • #1000533 filed against sphinxcontrib-htmlhelp.
  • #1000535 filed against sphinxcontrib-restbuilder.
  • #1000769 filed against node-marked.
  • #1000770 filed against perfect-scrollbar.
• Roland Clobus:
  • #1000674 and #1000685 filed against dictionaries-common (randomness in Ispell dictionaries)
• Simon McVittie:
  • #999552 filed against pcs.
• Vagrant Cascadian:
  • #998420 filed against minia.
  • #1000768 filed against krb5.
  • #1000836 filed against libu2f-host.
  • #1000839 filed against gutenprint.
  • #1000893 filed against bind9.
  • #1000897 filed against lift.
  • #1000921 filed against syncevolution.
  • #1000944 filed against apbs.
  • #1000945 filed against binutils-riscv64-unknown-elf.
  • #1000946 filed against gcc-riscv64-unknown-elf.
  • opensbi, which later led to a better patch on their mailing list.

Elsewhere, in software development, Jonas Witschel updated strip-nondeterminism, our tool to remove specific non-deterministic results from a completed build so that it did not fail on JAR archives containing invalid members with a .jar extension [ ]. This change was later uploaded to Debian by Chris Lamb. reprotest is the Reproducible Build s project end-user tool to build the same source code twice in widely different environments and checking whether the binaries produced by the builds have any differences. This month, Mattia Rizzolo overhauled the Debian packaging [ ][ ][ ] and fixed a bug surrounding suffixes in the Debian package version [ ], whilst Stefano Rivera fixed an issue where the package tests were broken after the removal of diffoscope from the package s strict dependencies [ ].

Testing framework The Reproducible Builds project runs a testing framework at tests.reproducible-builds.org, to check packages and other artifacts for reproducibility. This month, the following changes were made:

• Holger Levsen:
  • Document the progress in setting up snapshot.reproducible-builds.org. [ ]
  • Add the packages required for debian-snapshot. [ ]
  • Make the dstat package available on all Debian based systems. [ ]
  • Mark virt32b-armhf and virt64b-armhf as down. [ ]
• Jochen Sprickerhof:
  • Add SSH authentication key and enable access to the osuosl168-amd64 node. [ ][ ]
• Mattia Rizzolo:

  • Revert reproducible Debian: mark virt(32

    64)b-armhf as down - restored. [ ]

• Roland Clobus (Debian live image generation):
  • Rename sid internally to unstable until an issue in the snapshot system is resolved. [ ]
  • Extend testing to include Debian bookworm too.. [ ]
  • Automatically create the Jenkins view to display jobs related to building the Live images. [ ]
• Vagrant Cascadian:
  • Add a Debian package set group for the packages and tools maintained by the Reproducible Builds maintainers themselves. [ ]

---

If you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:

• IRC: #reproducible-builds on irc.oftc.net.
• Twitter: @ReproBuilds
• Mailing list: rb-general@lists.reproducible-builds.org

import smtplib

from email.mime.multipart import MIMEMultipart
from email.mime.image import MIMEImage

msg = MIMEMultipart('alternative')
msg['Subject'] = "subject"
msg['From'] = from_addr
msg['To'] = to_addr

part = MIMEImage(open('/path/to/image', 'rb').read())

s = smtplib.SMTP('localhost')
s.sendmail(from_addr, to_addr, msg.as_string())
s.quit()

import smtplib

from email.mime.multipart import MIMEMultipart
from email.mime.text import MIMEText
from email.mime.image import MIMEImage

msg = MIMEMultipart('alternative')
msg['Subject'] = "subject
msg['From'] = from_addr
msg['To'] = to_addr

text = MIMEText('<img src="cid:image1">', 'html')
msg.attach(text)

image = MIMEImage(open('/path/to/image', 'rb').read())

# Define the image's ID as referenced in the HTML body above
image.add_header('Content-ID', '<image1>')
msg.attach(image)

s = smtplib.SMTP('localhost')
s.sendmail(from_addr, to_addr, msg.as_string())
s.quit()